It is highly desirable for a communication operator to lower the complexity of operation and management tasks so as to lower an operation and maintenance cost. It is desirable to introduce a network self-organization mechanism to a next-generation network to thereby alleviate human participation in network planning, operation and maintenance so as to lower deployment and operation cost of the network. It is in view of this background that the characteristics of a Self-Organizing Network (SON) in the Evolved Universal Terrestrial Radio Access (E-UTRA) system have been studied as a work item in the 3rd Generation Partnership Project (3GPP). The SON technologies relate to self-configuration, self-optimization, and self-healing, where self-optimization is one of the important characteristics.
The SON self-optimization function needs to detect some network and system performance parameters as input, e.g., a statistic of a network performance index, a failure alarm, an alert, etc. After the input data is analyzed, a decision is made by using an optimization algorithm, and an adjusting operation of a related network node is finally triggered automatically.
In a mobile network, inappropriate setting of a handover parameter may seriously affect the performance of the system, and a call of a user may be dropped in a most serious case, so one of the most important issues to be addressed by the SON in the E-UTRA system is self-optimization of the handover parameter which is able to reduce handover failure, to reduce dropped call of the user due to an inappropriate handover, and to reduce unnecessary handover, thereby avoiding these handovers from accessing system resource uselessly. It is the first step for Mobility Robustness Optimization (MRO) to determine accurately an underlying cause of the failure.
The inappropriate handover typically arises from unreasonable setting of the handover parameter in the following several scenarios:
a) The terminal fails to be handed over to a cell with a better radio signal in a timely manner, and a signal of an original serving cell is deteriorating constantly until a call of the user is dropped, which can be referred to as “handover too late”, meaning that the handover should have been performed earlier but has been delayed due to inappropriate setting of the parameter;
b) The terminal is handed over from a source cell to a destination cell, but a signal of the destination cell is not stable, so that the terminal is subjected to a Radio Link Failure (RLF) shortly after the handover, and thereafter the terminal reselects a new cell to reestablish a connection, which can be referred to as “handover to wrong cell”, meaning that the cell to which the connection is reestablished is an appropriate cell indeed, whereas the originally selected destination cell is not appropriate; and
c) The terminal is handed over from a source cell to a destination cell, but the terminal is subjected to an RLF shortly, and thereafter the terminal selects the source cell to reestablish a connection, which can be referred to as “handover too early”.
Handover too late can be determined as per the following criterion:
The User Equipment (UE) (or referred to a terminal) is subjected to an RLF before the handover is triggered, and then the UE attempts on reestablishing a connection to another cell than the source cell.
Handover too early can be determined as per the following criterion:
The UE is subjected to an RLF shortly after being handed over to the destination cell, or is subjected to a HandOver Failure (HOF) during the handover, and then the UE attempts to reestablish a connection to the source cell.
Handover to wrong cell can be determined as per the following criterion:
The UE is subjected to an RLF (either in the source cell or in the destination cell) during the handover, or an RLF occurring shortly after being handed over to the destination cell, and then the UE attempts on reestablishing a connection to a third-party cell (other than the source cell and the destination cell).
In a real network, the UE is subjected to an RLF generally due to the following two reasons: firstly the handover parameter may be set inappropriately so that the serving cell of the UE fails to be changed in a timely manner, so the quality of a signal of the serving cell may be too low to provide the service, thus resulting in an RLF; and secondly there may be a coverage hole or shadowed fading in the network, and when the UE moves to the hole or a shadowed site, a radio link condition will be deteriorated sharply, thus resulting in an RLF.
Only the first reason relates to the handover problem, whereas the second reason relates to the coverage problem and will be precluded from MRO detection. These two reasons can be determined from Reference Signal Received Power (RSRP)/Reference Signal Received Qualities (RSRQs) of the current cell and an adjacent cell measured upon the failure. If RSRP/RSRQs of both the cells measured by the UE upon the failure are poor, then it indicates a coverage hole; otherwise, it indicates a handover problem. In order to assist the network side to determine an MRO, the UE needs to report information related to the connection failure (the RLF or the HOF), including the following items:
1. If the connection failure is the RLF, then the UE reports the ID of the last serving cell of the UE; and if the connection failure is the HOF, then the UE reports the ID of the destination cell to which the UE is handed over;
2. The ID of the cell to which a Radio Resource Control (RRC) connection is reestablished;
3. The ID of the cell from which the handover is initiated;
4. A period of time from the initiation of the last handover to the occurrence of the connection failure;
5. An indicator of whether the current failure is the RLF or the HOF; and
6. Measurement information including the RSRP/RSRQ of the serving cell, and the RSRP/RSRQ of the adjacent cell when the RLF occurs.
In the 3GPP specification, the UE will record the items 1, 3, 4, 5 and 6 above when the RLF or the HOF occurs, and the item 2 above when an RRC connection reestablishment request message is sent. The UE reports the recorded information related to the connection failure to the network side after the RRC connection is reestablished successfully or the RRC connection is established successfully. The network side determines from the information related to the connection failure, reported by the UE whether handover too early/handover too late/handover to wrong cell arises from the coverage problem or inappropriate setting of the handover parameter.
At present the UE subjected to the connection failure (the RLF or the HOF) will record a certain cell as a reestablishment cell as long as the UE is ready to initiate an RRC connection reestablishment request to the cell. However such a scenario is very like to occur that the cell may not satisfy a cell selection criterion after the UE initiates the RRC connection reestablishment request, or the UE may fail to receive an RRC connection reestablishment command sent by the network side after initiating the RRC connection reestablishment request. In this scenario, the UE may still report the information related to the connection failure, carrying the ID of the reestablishment cell, to the network side, and the network side will still regard the reestablishment cell as an appropriate cell, and perform determination and optimization of the MRO, thus optimizing the handover parameter incorrectly.
In summary, in the existing specification, the UE subjected to the connection failure will record a certain cell as a reestablishment cell, and report the ID of the reestablishment cell to the network side, as long as the UE is ready to initiate an RRC connection reestablishment request to the cell, so that the network side may optimize the handover parameter incorrectly in the scenario that the cell does not satisfy the preset cell selection criterion, or that the UE fails receive an RRC connection reestablishment command sent by the network side.